The invention relates to name resolution protocols, systems and methods for resolving a flat name space, such as the TL1 (Transaction Language 1) name space, to an address space, such as the IP (Internet Protocol) address space.
FIG. 1 is a block diagram of a typical system containing a SONET (synchronous optical network) ring configuration. The system consists of a SONET ring composed of a plurality (three shown) of SONET network elements 10,12,14, including a gateway SONET network element 10 in a central office 16, and two end office SONET network elements 12,14 in two end offices 18,20, the SONET network elements all being connected by a bi-directional fiber ring 20. Each end office SONET network element 12,14 is connected to a respective subscriber line multiplexing switch/device 24,26, which in turn is connected to subscriber devices (not shown) through respective groups of subscriber lines 28,30. Each SONET network element 10,12,14 performs add/drop multiplexing of SONET frames.
The network element 10 in the central office 16 is shown connected through a DCN (data communications network) cloud 32 to a NOC (network operations centre) 34 running an OS (operations system) 36. Operations staff work in the NOC 34 to perform OAM and P (operations, administration, maintenance and provisioning operations) functions through the operations system 36. The DCN cloud 32 may be any connection of routers/switchers/bridges and/or LAN/WAN links. The communications from the SONET network through the DCN 32 to the NOC 34 are all control communications, not regular traffic, such as voice traffic.
It has become somewhat the defacto standard that operations systems such as OS 36 use TL1 (Transaction Language 1xe2x80x94defined in BellCore Telecordia GR-831-CORE) to communicate with the networks they are being used to manage.
In accordance with TL1, each network element 10,12,14 is aware of its own respective unique SID (system identifier). In TL1, the identification of a network element""s SID is specified by a TID (target identifier) in a TL1 command from the OS 36 or in a response from a network element. It is the responsibility of the gateway network element 10 to route TL1 messages from the OS 36 to the appropriate network element based on the TID in each message. The gateway network element 10 communicates with the other network elements 12,14 using an embedded data communication channel, and thus a conversion from TL1 TIDs to the addresses of the embedded data communications channel must be made. Traditional SONET networks have used the OSI (Open Systems Interconnection) protocol suite over this embedded data communications channel, and this TID conversion function was done using TARP, another protocol specified in BellCore Telecordia GR-253-CORE.
Recently, efforts have been made to move away from the OSI protocol suite to use IP as the protocol over the embedded data communications channel. In such networks, the operations systems 36 would still be communicating in TL1, and thus the gateway network element 10 needs to perform address resolution from the TL1 name space to the IP space. The above identified TARP algorithm is an address resolution protocol originally designed to work in OSI networks, not IP networks. In theory, TARP could be adapted to work in an IP network. However, TARP relies on an inefficient packet flooding algorithm.
The Internet name space is hierarchical, with authoritative name servers translating names to IP addresses within that space. Domains can also be further subdivided into subdomains with authoritative servers for those subdomains. A lookup would start with the highest authoritative server (called root), walking through the hierarchy stopping at each authoritative server for each subdomain until the name has been resolved. The Domain Name System (DNS) has traditionally provided the name to IP address lookup functionality. DNS does not work for the TL1 name space because the TL1 name space is flat rather than hierarchical. The DNS root could be configured to understand all TL1 SIDs (system identifiers), but that would not work if the network elements are connected to the Internet because DNS would resolve all addresses to the well known DNS root server and that is where it would stop.
DNS was originally designed to work with static configuration tables which rarely changed. In a SONET network, network elements can be added, removed or may be isolated by fiber failure. While dynamic DNS (IETF RFC 2131) could be used to deal with this issue strictly in the IP domain, dynamic DNS does not solve the problem discussed above wherein SONET network elements are connected to the Internet.
LDAP (Light Weight Directory Access Protocol) is a distributed database that could also be used to solve the problem. This solution does not suffer from the DNS limitations, however it requires extra provisioning in the database records and a LDAP server each time a new network element is added.
Thus, to facilitate the implementation of IP-based SONET networks, it would be advantageous to have an efficient TL1 name to IP address resolution protocol.
Various embodiments of the invention provide network elements adapted to participate in an inventive name resolution protocol which performs name resolution from a flat name space, such as the TL1 name space, to an address space, such as the IP address space. Advantageously, a very efficient approach is used to resolving the flat name to the addresses which does not require any inefficient packet flooding, and which is adaptive to changes in a network which might occur.
One embodiment provides a network element adapted to implement the functionality by which a name resolution can be requested, i.e. the requesting functionality of the protocol. Such a network element has a first memory element adapted to store one or more local name of the network element, the local name belonging to one or more flat name spaces, and a processing element adapted to process a requested name by determining if the requested name is one of the local names, and if not to send a request message to a group of network addresses in the address space belonging to network elements which have joined the group, the request message containing the requested name for which a corresponding address is required.
The network element may further comprise a second memory element adapted to store previously resolved name-to-address mappings. In such a case, the processing element is adapted to process the requested name by determining if the requested name is one of the local names or a name of a previously resolved name-to-address mapping, and if not to send the request message.
The network element is typically further adapted to process a response messages specifying a particular network address for the requested name, and to add a name-to-address mapping to the second memory element identifying the particular network address as being the network address for the requested name.
The group of addresses might for example be a multicast group of IP addresses. The network element typically is equipped with an interface for receiving a command from an external source such as an operations system, the command specifying the requested name.
Another embodiment provides a network element adapted to perform the reporting functionality, i.e. to respond to requests generated as outlined above. Such a network element has a stack with a local address, and a memory element adapted to store one or more local names of the network element. The network element also has a procedure by which the network element joins a group of addresses, and request message processing functionality adapted to process a request message containing a requested name for which a corresponding address is required by comparing the requested name with the local names, and if there is a match with any one of these, to reply with a response message specifying the local address.
Network elements might be equipped with either or both of the requesting and reporting functionality. The network elements might for example form part of a network in which network elements are connected in an add/drop configuration so as to perform an add/drop multiplexing function on physical layer frames being transmitted on the network.
In embodiments employing the IP hierarchical address space, the network elements have a stack interface between IP packets and physical layer frames which might for example be SONET frames. The stack interface might for example be adapted to insert the IP packets in a channel defined by predetermined byte locations in the physical layer frames. In the event the physical layer frames are SONET frames, such predetermined byte locations might for example be SONET D1 to D12 overhead bytes.
Another embodiment provides a network of network elements each as summarized above, for example a SONET ring of network elements.
Advantageously, the solution does not require an additional provisioning on the network elements, and maintenance is not required when a network element is added to the system.
Further embodiments of the invention also include methods of realizing any of the above functionality, and include computer readable medium containing computer instructions which implement these instructions.